Hvordan fortryder jeg 'git add', inden jeg begår?

1
2
Næste
Du kan fortryde git-tilføjelse før du begår med
git reset 
som fjerner det fra det aktuelle indeks (listen "ved at blive forpligtet") uden at ændre noget andet.
Du kan bruge
git reset
uden noget filnavn for at fjerne alle grundige ændringer. Dette kan være nyttigt, når der er for mange filer til at blive opført en efter en på en rimelig tid.
I gamle versioner af Git svarer ovenstående kommandoer til henholdsvis git reset HEAD  og git reset HEAD og vil mislykkes, hvis HEAD er udefineret (fordi du endnu ikke har foretaget nogen forpligtelser i dit arkiv) eller tvetydig (fordi du oprettede en gren kaldet HEAD, hvilket er en dum ting, som du ikke skal gøre). Dette blev dog ændret i Git 1.8.2, så i moderne versioner af Git kan du bruge kommandoerne ovenfor selv inden du foretager din første forpligtelse:
"git reset" (uden optioner eller parametre) bruges til at fejle ud hvornår
du har ikke nogen forpligtelser i din historie, men det giver dig nu
et tomt indeks (for at matche ikke-eksisterende forpligtelse er du ikke engang på).
Dokumentation: git reset
|
Du vil have:
git rm --cached 
Ræsonnement:
Da jeg var ny på dette, prøvede jeg først
git reset.
(for at fortryde hele min oprindelige tilføjelse) kun for at få denne (ikke så) nyttige besked:
fatalt: Kunne ikke løse 'HEAD' som en gyldig ref.
Det viser sig, at dette er fordi HEAD ref (filial?) Ikke eksisterer før efter den første begåelse. Det vil sige, du løber ind i det samme begynderproblem som mig, hvis din arbejdsgang, som min, var noget som:
cd til min store nye projektmappe for at prøve Git, den nye hotness
git init
git add.
git-status
... masser af crap ruller efter ...
=> Damn, jeg ville ikke tilføje alt dette.
google "fortryd git tilføj"
=> find Stack Overflow - yay
git reset.
=> fatalt: Kunne ikke løse 'HEAD' som en gyldig ref.
Det viser sig desuden, at der er en fejl, der er logget mod, at det ikke er nyttigt i postlisten.
Og at den rigtige løsning var lige der i Git-statusoutputtet (som, ja, jeg glansede over som 'crap)
...
# Ændringer, der skal begås:
# (brug "git rm --cached  ..." for at fjerne scenen)
...
Og løsningen er faktisk at bruge git rm - cached FILE.
Bemærk advarslerne andetsteds her - git rm sletter din lokale arbejdskopi af filen, men ikke hvis du bruger --cached. Her er resultatet af git help rm:
--cache
Brug denne mulighed til kun at fjerne scener og fjerne stier fra indekset.
Arbejdende træfiler, uanset om de er ændret eller ej, bliver tilbage.
Jeg fortsætter med at bruge
git rm --cached.
for at fjerne alt og starte igen. Virkede dog ikke, for mens tilføj. er rekursiv, viser sig, at rm har brug for -r at recursere. Suk.
git rm -r --cached.
Okay, nu er jeg tilbage til hvor jeg startede. Næste gang jeg skal bruge -n til at lave et tørløb og se, hvad der tilføjes:
git add -n.
Jeg zippede alt op på et sikkert sted, før jeg stolede på git-hjælp rm om --cachen, der ikke ødelagde noget (og hvad hvis jeg stavede det forkert).
|
Hvis du skriver:
git-status
Git fortæller dig, hvad der er iscenesat osv., Herunder instruktioner om, hvordan du afbryder scenen:
brug "git reset HEAD  ..." for at fjerne scenen
Jeg finder ud af, at Git gør et ret godt stykke arbejde med at skubbe mig til at gøre det rigtige i situationer som denne.
Bemærk: Seneste Git-versioner (1.8.4.x) har ændret denne meddelelse:
(brug "git rm --cached  ..." for at fjerne scenen)
|
For at afklare: git add flytter ændringer fra den aktuelle arbejdsmappe til mellemstationer (indeks).
Denne proces kaldes iscenesættelse. Så den mest naturlige kommando til at gennemføre ændringerne (ændrede filer) er den åbenlyse:
git scene
git add er bare et lettere alias for git-scenen
Synd, der er ingen git unstage eller git unadd kommandoer. Den relevante er sværere at gætte eller huske, men det er ret indlysende:
git reset HEAD -
Vi kan nemt oprette et alias til dette:
git config --global alias.unadd 'nulstil HEAD -'
git config --global alias.unstage 'reset HEAD -'
Og endelig har vi nye kommandoer:
git tilføj fil 1
git fase fil2
git unadd-fil2
git unstage-fil1
Personligt bruger jeg endnu kortere aliasser:
git a # Til iscenesættelse
git u # Til afvikling
|
En tilføjelse til det accepterede svar, hvis din fejlagtigt tilføjede fil var enorm, vil du sandsynligvis bemærke, at den selv efter at have fjernet den fra indekset med 'git reset' stadig synes at optage plads i .git-biblioteket.
Dette er intet at være bekymret for; filen er faktisk stadig i arkivet, men kun som en "løs genstand". Det vil ikke blive kopieret til andre arkiver (via klon, push), og rummet vil til sidst blive genvundet - dog måske ikke meget snart. Hvis du er nervøs, kan du løbe:
git gc - beskære = nu
Opdatering (det følgende er mit forsøg på at fjerne forvirring, der kan opstå på grund af de mest opstemte svar):
Så hvad er den reelle fortrydelse af git add?
git reset HEAD ?
eller
git rm --cached ?
Strengt taget, og hvis jeg ikke tager fejl: ingen.
git add kan ikke fortrydes - generelt generelt.
Lad os først huske, hvad git add  faktisk gør:
Hvis  ikke tidligere blev sporet, tilføjer git add det tilcachen med det aktuelle indhold.
Hvis  allerede blev sporet, gemmer git add det aktuelle indhold (øjebliksbillede, version) i cachen. I Git kaldes denne handling stadig tilføj (ikke kun opdatering), fordi to forskellige versioner (snapshots) af en fil betragtes som to forskellige emner: Derfor tilføjer vi faktisk et nyt emne til cachen, som i sidste ende begået senere.
I lyset af dette er spørgsmålet lidt tvetydigt:
Jeg tilføjede fejlagtigt filer ved hjælp af kommandoen ...
OP's scenarie ser ud til at være det første (ikke-sporet fil), vi vil have "fortryd" for at fjerne filen (ikke kun det aktuelle indhold) fra de sporede emner. Hvis dette er tilfældet, er det ok at køre git rm --cached .
Og vi kunne også køre git reset HEAD . Dette er generelt at foretrække, fordi det fungerer i begge scenarier: det gør også fortrydelsen, når vi fejlagtigt tilføjede en version af et allerede sporet element.
Men der er to forbehold.
For det første: Der er (som påpeget i svaret) kun et scenarie, hvor git reset HEAD ikke fungerer, men git rm --cached gør: et nyt lager (ingen forpligtelser). Men virkelig, dette er en praktisk talt irrelevant sag.
For det andet: Vær opmærksom på, at git reset HEAD ikke magisk kan gendanne det tidligere cachelagrede filindhold, det synkroniserer det bare fra HEAD. Hvis vores vildledte git-tilføjelse overskrev en tidligere iscenesat ikke-forpligtet version, kan vi ikke gendanne den. Derfor kan vi strengt taget ikke fortryde [*].
Eksempel:
$ git init
$ echo "version 1"> file.txt
$ git tilføj file.txt # Første tilføjelse af file.txt
$ git commit -m 'first commit'
$ echo "version 2"> file.txt
$ git tilføj file.txt # Stage (ikke begå) "version 2" af file.txt
$ git diff - cached file.txt
-version 1
+ version 2
$ echo "version 3"> file.txt
$ git diff file.txt
-version 2
+ version 3
$ git add file.txt # Ups, vi mente ikke dette
$ git nulstil HEAD file.txt # Fortryd?
$ git diff --cached file.txt # Ingen forskel, selvfølgelig. fase == HOVED
$ git diff file.txt # Vi har uigenkaldeligt mistet "version 2"
-version 1
+ version 3
Selvfølgelig er dette ikke særlig kritisk, hvis vi bare følger den sædvanlige dovne arbejdsgang med at udføre 'git add' kun for at tilføje nye filer (sag 1), og vi opdaterer nyt indhold via kommandoen commit, git commit -a.
* (Rediger: ovenstående er praktisk taget korrekt, men der kan stadig være nogle lidt hackede / indviklede måder til at gendanne ændringer, der blev iscenesat, men ikke begået og derefter overskrevet - se kommentarerne fra Johannes Matokic og iolsmit)
|
Fortryd en fil, der allerede er tilføjet, er ret let ved hjælp af Git. For at nulstille myfile.txt, som allerede er tilføjet, skal du bruge:
git reset HEAD myfile.txt
Forklaring:
Når du har iscenesat uønskede filer, kan du git nulstille for at fortryde det. Hoved er leder af din fil i den lokale, og den sidste parameter er navnet på din fil.
Jeg har oprettet trinene i billedet nedenfor i flere detaljer for dig, inklusive alle trin, der kan ske i disse tilfælde:
|
git rm --cached. -r
vil "fjerne tilføjelse" af alt, hvad du har tilføjet fra din nuværende mappe rekursivt
|
Løb
git gui
og fjern alle filerne manuelt eller ved at markere dem alle og klikke på unstage from commit-knappen.
|
Spørgsmålet er ikke klart stillet. Årsagen er, at git add har to betydninger:
tilføje en ny fil til iscenesættelsesområdet, og fortryd derefter med git rm - cached-fil.
tilføje en ændret fil til iscenesættelsesområdet, og fortryd derefter med git reset HEAD-fil.
Brug i tvivlstilfælde
git nulstil HEAD-fil
Fordi det gør det forventede i begge tilfælde.
Advarsel: Hvis du git rm - cached fil på en fil, der blev ændret (en fil, der eksisterede før i arkivet), fjernes filen efter git commit! Det vil stadig eksistere i dit filsystem, men hvis nogen andre trækker din forpligtelse, slettes filen fra deres arbejdstræ.
git-status fortæller dig, om filen var en ny fil eller ændret:
Om filialmester
Ændringer, der skal begås:
(brug "git reset HEAD  ..." for at fjerne scenen)
ny fil: my_new_file.txt
ændret: my_modified_file.txt
|
Git har kommandoer til enhver tænkelig handling, men den har brug for omfattende viden for at få tingene rigtige, og på grund af det er det i bedste fald kontraintuitivt ...
Hvad du gjorde før:
Ændrede en fil og brugte git add. Eller git add .
Hvad du vil have:
Fjern filen fra indekset, men hold den versioneret og efterlad med uforpligtede ændringer i arbejdskopien:
git reset HEAD 
Nulstil filen til den sidste tilstand fra HEAD, fortryd ændringer og fjern dem fra indekset:
# Tænk `svn gendanne ` IIRC.
git reset HEAD 
git checkout 
# Hvis du har en "" med navnet "", skal du bruge:
git checkout - 
Dette er nødvendigt, da git reset - hårdt HEAD fungerer ikke med enkeltfiler.
Fjern  fra indeks og versionering, og hold den ikke-versionerede fil med ændringer i arbejdskopien:
git rm --cached 
Fjern  fra arbejdskopi og versionering fuldstændigt:
git rm 
|
Hvis du er på din første forpligtelse, og du ikke kan bruge gitnulstil, kun erklær "Git konkurs" og slet .git-mappen og start forfra
|
Som i mange af de andre svar kan du bruge git reset
MEN:
Jeg fandt dette fantastiske lille indlæg, der faktisk tilføjer Git-kommandoen (ja, et alias) for git unadd: se git unadd for detaljer eller ..
Ganske enkelt,
git config --global alias.unadd "reset HEAD"
Nu kan du
git unadd foo.txt bar.txt
|
Brug git add -i til at fjerne netop tilføjede filer fra din kommende forpligtelse. Eksempel:
Tilføjelse af den fil, du ikke ønskede:
$ git tilføj foo
$ git-status
# Om filialmester
# Ændringer, der skal begås:
# (brug "git reset HEAD  ..." for at fjerne scenen)
#
# ny fil: foo
#
# Usporede filer:
# (brug "git tilføj  ..." for at medtage i det, der vil blive begået)
# [...] #
Gå til interaktiv tilføjelse for at fortryde din tilføjelse (kommandoerne, der er skrevet ved git her, er "r" (tilbageførsel), "1" (første post i listen viser tilbagekaldelse), "return" for at droppe fra tilbageførselstilstand og "q" (Afslut):
$ git add -i
iscenesat ustadisk sti
1: + 1 / -0 intet foo
*** Kommandoer ***
1: [s] tatus 2: [u] pdate 3: [r] evert 4: [a] dd untracked
5: [p] atch 6: [d] iff 7: [q] uit 8: [h] elp
Hvad nu> r
iscenesat ikke-iscenesat sti
1: + 1 / -0 intet [f] oo
Vend tilbage >> 1
iscenesat ikke-iscenesat sti
* 1: + 1 / -0 intet [f] oo
Vend tilbage >>
Bemærk: foo er ikke sporet nu.
vendte en vej tilbage
*** Kommandoer ***
1: [s] tatus 2: [u] pdate 3: [r] evert 4: [a] dd untracked
5: [p] atch 6: [d] iff 7: [q] uit 8: [h] elp
Hvad nu> q
Farvel.
$
Det er det! Her er dit bevis, der viser, at "foo" er tilbage på den ikke-sporede liste:
$ git-status
# Om filialmester
# Usporede filer:
# (brug "git tilføj  ..." for at medtage i det, der vil blive begået)
# [...]
# foo
intet tilføjet for at begå, men ikke-sporede filer til stede (brug "git add" for at spore)
$
|
git remove eller git rm kan bruges til dette med flag --cached. Prøve:
git hjælp rm
|
Her er en måde at undgå dette irriterende problem, når du starter et nyt projekt:
Opret hovedmappen til dit nye projekt.
Kør git init.
Opret nu en .gitignore-fil (selvom den er tom).
Forpligt din .gitignore-fil.
Git gør det virkelig svært at git reset, hvis du ikke har nogen forpligtelser. Hvis du opretter en lille indledende forpligtelse bare for at have en, efter det kan du git add-A og git reset så mange gange som du vil for at få alt rigtigt.
En anden fordel ved denne metode er, at hvis du løber ind i problemer med linjeslutning senere og har brug for at opdatere alle dine filer, er det let:
Tjek den oprindelige forpligtelse. Dette fjerner alle dine filer.
Tjek derefter din seneste forpligtelse igen. Dette vil hente friske kopier af dine filer ved hjælp af dine nuværende indstillinger for linjeafslutning.
|
Måske har Git udviklet sig, siden du stillede dit spørgsmål.
$> git --version
git version 1.6.2.1
Nu kan du prøve:
git reset HEAD.
Dette skal være det, du leder efter.
|
Bemærk, at hvis du ikke angiver en revision, skal du medtage en separator. Eksempel fra min konsol:
git nulstil 
fatalt: tvetydigt argument '': ukendt revision eller sti ikke i arbejdstræet.
Brug '-' til at adskille stier fra revisioner
git reset - 
Ikke-trinvise ændringer efter nulstilling:
M 
(Git version 1.7.5.4)
|
Sådan fjernes nye filer fra iscenesættelsesområdet (og kun i tilfælde af en ny fil) som foreslået ovenfor:
git rm --cached FILE
Brug kun rm - cached til nye filer, der ved et uheld er tilføjet.
|
For at nulstille hver fil i en bestemt mappe (og dens undermapper) kan du bruge følgende kommando:
git reset *
|
Brug * kommandoen til at håndtere flere filer ad gangen:
git reset HEAD * .prj
git reset HEAD * .bmp
git reset HEAD * gdb *
etc.
|
Bare skriv git reset, det vender tilbage, og det er som om du aldrig har skrevet git add. siden din sidste forpligtelse. Sørg for, at du har forpligtet dig før.
|
Antag, at jeg opretter en ny fil, newFile.txt:
Antag, at jeg tilføjer filen ved et uheld, git tilføj newFile.txt:
Nu vil jeg fortryde denne tilføjelse, inden du begår, git reset newFile.txt:
|
For en bestemt fil:
git nulstil my_file.txt
git checkout my_file.txt
For alle tilføjede filer:
git reset.
git checkout.
Bemærk: kassen ændrer koden i filerne og flytter til den sidst opdaterede (forpligtede) tilstand. nulstilling ændrer ikke koderne; det nulstiller bare overskriften.
|
For at fortryde git-tilføjelse skal du bruge:
git nulstil filnavn
|
Denne kommando fjerner dine ændringer:
git nulstil HEAD filnavn.txt
Du kan også bruge
git add -p
for at tilføje dele af filer.
|
Der er også interaktiv tilstand:
git add -i
Vælg mulighed 3 for at fjerne tilføjelse af filer. I mit tilfælde vil jeg ofte tilføje mere end en fil, og med interaktiv tilstand kan du bruge numre som dette til at tilføje filer. Dette tager alt undtagen 4: 1, 2, 3 og 5
For at vælge en sekvens skal du bare skrive 1-5 for at tage alt fra 1 til 5.
Git iscenesættelse af filer
|
git add myfile.txt # Dette tilføjer din fil til listen over forpligtelser
Helt modsat af denne kommando er,
git reset HEAD myfile.txt # Dette fortrydesdet.
så du vil være i den tidligere tilstand. Angivet vil være igen på en ikke-sporet liste (tidligere tilstand).
Det nulstiller dit hoved med den angivne fil. så hvis dit hoved ikke betyder det, nulstiller det det simpelthen.
|
git nulstil filnavn.txt
Fjerner en fil med navnet filnavn.txt fra det aktuelle indeks, området "ved at blive forpligtet" uden at ændre noget andet.
|
git nulstil filnavn.txt
Fjerner en fil med navnet filnavn.txt fra det aktuelle indeks, området "ved at blive forpligtet" uden at ændre noget andet.
|
I Sourcetree kan du nemt gøre dette via GUI.
Du kan kontrollere, hvilken kommando Sourcetree bruger til at fjerne scenen på en fil.
Jeg oprettede en ny fil og tilføjede den til Git. Derefter afmonterede jeg det ved hjælp af Sourcetree GUI.
Dette er resultatet:
Fjernelse af iscenesættelse af filer [08/12/15 10:43]
git -c diff.mnemonicprefix = false -c core.quotepath = false -c credential.helper = sourcetree reset -q - sti / til / fil / filnavn.java
Sourcetree bruger reset til at afvikle nye filer.
|
1
2
Næste
Meget aktivt spørgsmål. Optjen 10 omdømme for at besvare dette spørgsmål. Omdømmekravet hjælper med at beskytte dette spørgsmål mod spam og ikke-svar-aktivitet.
Er det ikke det svar, du leder efter? Gennemse andre spørgsmål, der er tagget git version-control git-commit git-stage, eller stil dit eget spørgsmål.